A large software development environment relies on many developers, or software engineers, developing systems including many software elements. Each software element includes multiple objects, and is spread across many files. Typically, the files include source code, or human readable versions, of computer instructions, and are modifiable by the developers. As is known in the industry, the source code is compiled into object code and eventually into executable code, which is a set of instructions executable by a processor on the target machine for which the system was developed. The process of transforming the source code to the executable (running) system is known as a build, and involves a series of transformations from source code to executable code.
Software objects in conventional software systems include or inherit methods and attributes from other objects in the system. Inheritance is usually defined in terms of classes, which inherit other classes (or subclasses), resulting in a complex hierarchical or matrix pattern of inheritance, often called an inheritance lattice. Inheritance results in a dependency between the objects or classes, as changes to a particular class triggers a need to propagate the change to classes which inherit, or depend on, the changed class. Such dependencies are resolved by a build, which recompiles the affected entities to propagate the changes to dependent classes. In a large software system, the build can become substantial, and a modification to a particular class or object can have a rippling effect which traverses the inheritance lattice defined by the dependencies.
Modern software development methodologies are exhibiting a trend toward so-called middleware based implementations. Middleware provides a vendor and platform independent interprocess communication mechanism using generic objects which may be instantiated under one platform or OS and received by another using the underlying mechanism provided by the middleware. A middleware based application may be ported, or rebuilt, simply by rebuilding on another middleware platform without modifying non-middleware aspects.
One popular middleware implementation is CORBA. CORBA is the acronym for Common Object Request Broker Architecture, OMG's open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.
Middleware such as CORBA may be beneficial in many situations. Because of the straightforward manner that CORBA integrates machines from so many vendors, with sizes ranging from mainframes through minis and desktops to hand-helds and embedded systems, it is the middleware of choice for large (and even not-so-large) enterprises. One of its most important, as well most frequent, uses is in servers that must handle large number of clients, at high hit rates, with high reliability.
CORBA applications are composed of objects, individual units of running software that combine functionality and data, and that frequently (but not always) represent something in the real world. In a typical middleware based object oriented architecture, there are many instances of an object of a single type—for example, an e-commerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer, and contains data representing the merchandise that its particular customer has selected. For other types, there may be only one instance. When a legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on the network, there is typically only one instance.